Smart Process Modules and Objects in Process Plants

ABSTRACT

An operator interface within a process plant includes an execution engine that implements process flow modules made up of interconnected smart process objects that are aware of devices and other entities within the plant and that can perform methods to detect conditions within the plant, especially on a system-level basis. The smart process objects include a display element to be displayed to the operator, data storage for storing data pertaining to and/or received from an associated entity within a plant, inputs and outputs for communicating with other smart process objects and methods that may be executed on the data to detect plant conditions, including system-level conditions, such as leaks, errors and other conditions. Process flow modules, which may be made up of numerous interconnected smart process objects, may also include flow algorithms associated therewith to calculate mass balances, flows, etc. for the process elements within the process flow modules.

RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.11/567,116, filed Dec. 5, 2006, entitled “Smart Process Modules andObjects in Process Plants,” which is a continuation of U.S. patentapplication Ser. No. 10/278,469 filed Oct. 22, 2002, entitled “SmartProcess Modules and Objects in Process Plants,” the entire disclosuresof each of which are hereby expressly incorporated by reference hereinfor all purposes.

TECHNICAL FIELD

The present invention relates generally to process plants and, moreparticularly, to an intelligent operator environment that enablesviewing and device condition detection functionality at the system levelof a distributed control process plant.

DESCRIPTION OF THE RELATED ART

Distributed process control systems, like those used in chemical,petroleum or other processes, typically include one or more processcontrollers communicatively coupled to one or more field devices viaanalog, digital or combined analog/digital buses. The field devices,which may be, for example, valves, valve positioners, switches andtransmitters (e.g., temperature, pressure, level and flow rate sensors),are located within the process environment and perform process functionssuch as opening or closing valves, measuring process parameters, etc.Smart field devices, such as the field devices conforming to thewell-known Fieldbus protocol may also perform control calculations,alarming functions, and other control functions commonly implementedwithin the controller. The process controllers, which are also typicallylocated within the plant environment, receive signals indicative ofprocess measurements made by the field devices and/or other informationpertaining to the field devices and execute a controller applicationthat runs, for example, different control modules which make processcontrol decisions, generate control signals based on the receivedinformation and coordinate with the control modules or blocks beingperformed in the field devices, such as HART and Fieldbus field devices.The control modules in the controller send the control signals over thecommunication lines to the field devices to thereby control theoperation of the process.

Information from the field devices and the controller is usually madeavailable over a data highway to one or more other hardware devices,such as operator workstations, personal computers, data historians,report generators, centralized databases, etc., typically placed incontrol rooms or other locations away from the harsher plantenvironment. These hardware devices run applications that may, forexample, enable an operator to perform functions with respect to theprocess, such as changing settings of the process control routine,modifying the operation of the control modules within the controller orthe field devices, viewing the current state of the process, viewingalarms generated by field devices and controllers, simulating theoperation of the process for the purpose of training personnel ortesting the process control software, keeping and updating aconfiguration database, etc.

As an example, the DeltaV™ control system, sold by Fisher-RosemountSystems, Inc. includes multiple applications stored within and executedby different devices located at diverse places within a process plant. Aconfiguration application, which resides in one or more operatorworkstations, enables users to create or change process control modulesand download these process control modules via a data highway todedicated distributed controllers. Typically, these control modules aremade up of communicatively interconnected function blocks, which areobjects in an object oriented programming protocol, which performfunctions within the control scheme based on inputs thereto and whichprovide outputs to other function blocks within the control scheme. Theconfiguration application may also allow a designer to create or changeoperator interfaces which are used by a viewing application to displaydata to an operator and to enable the operator to change settings, suchas set points, within the process control routine. Each dedicatedcontroller and, in some cases, field devices, stores and executes acontroller application that runs the control modules assigned anddownloaded thereto to implement actual process control functionality.The viewing applications, which may be run on one or more operatorworkstations, receive data from the controller application via the datahighway and display this data to process control system designers,operators, or users using the user interfaces, and may provide any of anumber of different views, such as an operator's view, an engineer'sview, a technician's view, etc. A data historian application istypically stored in and executed by a data historian device thatcollects and stores some or all of the data provided across the datahighway while a configuration database application may run in a stillfurther computer attached to the data highway to store the currentprocess control routine configuration and data associated therewith.Alternatively, the configuration database may be located in the sameworkstation as the configuration application.

As noted above, operator display applications are typically implementedon a system wide basis in one or more of the workstations and providepreconfigured displays to the operator or maintenance persons regardingthe operating state of the control system or the devices within theplant. Typically, these displays take the form of alarming displays thatreceive alarms generated by controllers or devices within the processplant, control displays indicating the operating state of thecontrollers and other devices within the process plant, maintenancedisplays indicating the operating state of the devices within theprocess plant, etc. These displays are generally preconfigured todisplay, in known manners, information or data received from the processcontrol modules or the devices within the process plant. In some knownsystems, displays are created through the use of objects that have agraphic associated with a physical or logical element and that iscommunicatively tied to the physical or logical element to receive dataabout the physical or logical element. The object may change the graphicon the display screen based on the received data to illustrate, forexample, that a tank is half full, to illustrate the flow measured by aflow sensor, etc. While the information needed for the displays is sentfrom the devices or configuration database within the process plant,that information is used only to provide a display to the usercontaining that information. As a result, all information andprogramming that is used to generate alarms, detect problems within theplant, etc. must be generated by and configured within the differentdevices associated with the plant, such as controllers and field devicesduring configuration of the process plant control system. Only then isthis information sent to the operator display for display during processoperation.

While error detection and other programming is useful for detectingconditions, errors, alarms, etc. associated with control loops runningon the different controllers and problems within the individual devices,it is difficult to program the process plant to recognize system-levelconditions or errors that must be detected by analyzing data fromdifferent, possible diversely located devices within the process plant.Still further, operator displays have typically not been used toindicate or present such system-level condition information to operatorsor maintenance personnel and, in any event, it is difficult to animateobjects within operator displays with these alternate sources ofinformation or data for the different elements within the display.Moreover, there is currently no organized manner of detecting certainconditions within a plant, such as flow conditions and mass balances, asmaterials move through a plant, much less an easily implementable systemfor performing these functions on a system-level basis.

SUMMARY

An operator workstation or other computer runs an execution engine thatexecutes process flow modules made up of interconnected smart processobjects, each of which displays information about a particular entitywithin the process and which may include behavior or methods that can beused to detect conditions within the plant. The process flow modules mayalso include behavior or methods, called flow algorithms, that can beused to detect process conditions, especially on a system-level basis.The smart process objects may include a display element to be displayedto the operator, data storage for storing data pertaining to andreceived from an associated entity within a plant, inputs and outputsfor communicating with other smart process objects and methods that maybe executed on the stored and received data to detect plant or deviceconditions, such as leaks, errors and other conditions. The smartprocess objects may be communicatively connected together to create aprocess flow module that provides a display for, and implements a set ofrules for a plant entity, such as an area, device, element, module, etc.

In one embodiment, each smart process object is associated with a plantentity, such as a field device, controller, or logical element, andincludes a data store for parameter or variable data associated withthat entity. The smart process object is communicatively coupled to theentity, either directly or through a configuration database, to receivedata associated with that entity. Each smart process object may also becommunicatively coupled to other smart process objects within theoperator interface to send data to and receive data from the other smartprocess objects and may include methods or routines for operating on thedata available to the smart process object to detect conditionsassociated with the device or plant. For example, a smart process objectfor a tank may be coupled to smart process objects for pumps or flowtransmitters upstream and downstream of the tank and receive dataindicative of the upstream and downstream flows into and out of thetank. A method associated with the tank object may detect leaks in thetank by comparing the level of the tank with the expected level in thetank based on the flows into and out of the tank. Still further, theprocess flow modules may include flow algorithms that can be implementedon the combination of entities therein to detect system-levelconditions, for example, to detect mass balances, flow conditions, etc.

The smart process objects and process flow modules enable theimplementation of condition and error detection routines at the operatordisplay device, and may work together with or eliminate the need toprovide this functionality down within the controller and field devicesof the plant. These smart process objects and process flow modules alsoprovide the operator with another degree of programming flexibilitywithin the process plant that can be used to provide better and morecomplete information to the operator while still being easy to use andimplement. Still further, the operator displays may be animated withinformation determined by or calculated by flow algorithms of theprocess flow modules.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a distributed process control networklocated within a process plant including an operator workstation thatimplements a display routine which uses smart process objects andprocess flow modules to analyze the process plant;

FIG. 2 is a logical block diagram of a set of applications and otherentities, including smart process objects and process flow modules,stored in the operator workstation of FIG. 1, which may be used toimplement enhanced functionality in a process plant;

FIG. 3 is a depiction of a configuration screen used by an operator tocreate a process display using smart process objects stored in an objectlibrary;

FIG. 4 is a screen display illustrating an operator interface generatedby a process flow module using multiple smart process objects; and

FIG. 5 is a logical block diagram of a manner in which process flowmodules using smart process objects may be created in and implementedwithin an existing process control network.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring now to FIG. 1, a process plant 10 uses a distributed processcontrol system having one or more controllers 12, each connected to oneor more field devices 14 and 16 via input/output (I/O) devices or cards18 which may be, for example, Fieldbus interfaces, Profibus interfaces,HART interfaces, standard 4-20 ma interfaces, etc. The controllers 12are also coupled to one or more host or operator workstations 20 and 22via a data highway 24 which may be, for example, an Ethernet link.Furthermore, a database 28 may be connected to the data highway 24 andoperates as a data historian that collects and stores parameter, statusand other data associated with the controllers and field devices withinthe plant 10 and/or as a configuration database that stores the currentconfiguration of the process control system within the plant 10 asdownloaded to and stored within the controllers 12 and field devices 14and 16. While the controllers 12, input/output cards 18 and fielddevices 14 and 16 are typically located down within and distributedthroughout the sometimes harsh plant environment, the operatorworkstations 20 and 22 and the database 28 are usually located incontrol rooms or other less harsh environments easily assessable bycontroller or maintenance personnel.

As is known, each of the controllers 12, which may be by way of example,the DeltaV controller sold by Fisher-Rosemount Systems, Inc., stores andexecutes a controller application that implements a control strategyusing a number of different, independently executed, control modules orblocks. The control modules may each be made up of what are commonlyreferred to as function blocks wherein each function block is a part ora subroutine of an overall control routine and operates in conjunctionwith other function blocks (via communications called links) toimplement process control loops within the process plant 10. As is wellknown, function blocks, which may be objects in an object orientedprogramming protocol, typically perform one of an input function, suchas that associated with a transmitter, a sensor or other processparameter measurement device, a control function, such as thatassociated with a control routine that performs PID, fuzzy logic, etc.control, or an output function which controls the operation of somedevice, such as a valve, to perform some physical function within theprocess plant 10. Of course hybrid and other types of complex functionblocks exist such as model predictive controllers (MPCs), optimizers,etc While the Fieldbus protocol and the DeltaV system protocol usecontrol modules and function blocks designed and implemented in anobject oriented programming protocol, the control modules could bedesigned using any desired control programming scheme including, forexample, sequential function block, ladder logic, etc. and are notlimited to being designed using function block or any other particularprogramming technique.

In the system illustrated in FIG. 1, the field devices 14 and 16connected to the controllers 12 may be standard 4-20 ma devices, may besmart field devices, such as HART, Profibus, or FOUNDATION™ Fieldbusfield devices, which include a processor and a memory, or may be anyother desired type of device. Some of these devices, such as Fieldbusfield devices (labeled with reference number 16 in FIG. 1), may storeand execute modules, or sub-modules, such as function blocks, associatedwith the control strategy implemented in the controllers 12. Functionblocks 30, which are illustrated in FIG. 1 as being disposed in twodifferent ones of the Fieldbus field devices 16, may be executed inconjunction with the execution of the control modules within thecontrollers 12 to implement process control, as is well known. Ofcourse, the field devices 14 and 16 may be any types of devices, such assensors, valves, transmitters, positioners, etc. and the PO devices 18may be any types of PO devices conforming to any desired communicationor controller protocol such as HART, Fieldbus, Profibus, etc.

In the process plant 10 of FIG. 1, the workstation 20 includes a suiteof operator interface applications and other data structures 32 whichcan be accessed by any authorized user (referred to herein as anoperator) to view and provide functionality with respect to devicesconnected within the process plant 10. The suite of operator interfaceapplications 32 is stored in a memory 34 of the workstation 20 and eachof the applications or entities within the suite of applications 32 isadapted to be executed on a processor 36 associated with the workstation20. While the entire suite of applications 32 is illustrated as beingstored in the workstation 20, some of these applications or otherentities could be stored in an executed in other workstations orcomputer devices within or associated with the plant 10. Furthermore,the suite of applications can provide display outputs to a displayscreen 37 associated with the workstation 20 or any other desireddisplay screen or display device, including hand-held devices, laptops,other workstations, printers, etc. Likewise, the applications within thesuite of applications 32 may be broken up and executed on two or morecomputers or machines and be configured to operated in conjunction withone another.

FIG. 2 illustrates some of the applications and data structures or otherentities within the suite of applications (and other entities) 32 of theworkstation 20. In particular, the suite of applications 32 includes aprocess flow module configuration application 38 which is used by anoperator to create process flow modules (and associated displays) usingone or more smart process objects. A library 40 of smart process objects42 includes example or template smart process objects that may beaccessed, copied and used by the configuration application 38 to createprocess flow modules 44. As will be understood, the configurationapplication 38 may be used to create one or more process flow modules44, each of which is made up of one or more smart process objects andmay include one or more process flow algorithms 45, which are stored ina process flow module memory 46. One of the process flow modules 44 b isillustrated in FIG. 2 in expanded form and includes a set of processelements, such as valves, tanks, sensors and flow transmitters,interconnected by connections elements which may be pipes, conduit,wires, conveyors, etc.

An execution engine 48 operates or implements each of the process flowmodules 44 during runtime to create one or more process displays for anoperator as defined by the process flow modules 44 and to implementadditional functionality associated with the process flow modules 44 andwith the smart process objects within the process flow modules 44. Theexecution engine 48 may use a rules database 50 defining the logic to beimplemented on the process flow modules 44 as a whole and the smartprocess objects within those modules in particular. The execution engine48 may also use a connection matrix 52 which defines the connectionsbetween the process elements within the plant 10 as well as within theprocess flow modules 44 to implement the functionality for the processflow modules 44.

FIG. 2 illustrates one of the smart process objects 42 e in more detail.While the smart process object 42 e is illustrated as being one of thetemplate smart process objects, it will be understood that other smartprocess objects will generally include the same or similar elements,features, parameters, etc. as described with respect to the smartprocess object 42 e and that the specifics or values of these elements,features and parameters may be changed or varied from smart processobject to smart process object depending on the nature and use of thatsmart process object. Furthermore, while the smart process object 42 emay be an object within an object oriented programming environment andthus include data stores, inputs and outputs and methods associatedtherewith, this smart process object may be created by and implementedwithin any other desired programming paradigm or protocol.

As will be understood, the smart process object 42 e is an object thatis associated with a particular entity, such as a physical or a logicalentity, within the process plant 10 of FIG. 1. The smart process object42 e includes a data store 53 that is used to store data received fromor pertaining to the logical entity with which the smart process object42 e is associated. The data store 53 generally includes a data store 53a that stores general or permanent information about the entity to whichthe smart process object 42 e pertains, like manufacturer, revision,name, type, etc. A data store 53 b may store variable or changing data,such as parameter data, status data, input and output data, or otherdata about the entity to which the smart process object 42 e pertainsincluding data associated with the entity as it has existed in the pastor as it now exists within the process plant 10. Of course, the smartprocess object 42 e may be configured or programmed to receive this dataon a periodic or non-periodic basis, from the entity itself via anydesired communication link, from the historian 28 via the Ethernet bus24 or in any other desired manner. A data store 53 c may store agraphical representation of the entity to which the smart process object42 e pertains and which is used for actual display to the operator viaan operator interface, such as the screen 37 associated with theworkstation 20 of FIG. 1. Of course, the graphical representation mayinclude place holders (marked by underlines within the data store 53 c)for information about the entity, such as information defined by theparameter or other variable data about the entity as stored in the datastore 53 b. This parameter data may be displayed in the graphical placeholders when the graphical representation is presented to the operatoron a display device 37. The graphical representation (and the smartprocess object 42 c) may also include predefined connection points(marked by an “X” in the data store 53 c) that enable an operator toattach upstream or downstream components to the process element, asdepicted by the graphical representation. Of course, these connectionpoints also enable the smart process object 42 e to be aware of theelements connected to that smart object as configured within a processflow module.

The smart process object 42 e may also include one or more inputs 54 andoutputs 56 to enable communication with other smart process objectswithin or outside of a process flow module in which the smart processobject 42 is placed. The connections of the inputs 54 and outputs 56 toother smart process objects may be configured by an operator duringconfiguration of a process flow module by simply connecting other smartprocess objects to these inputs and outputs or by specifying particularcommunications that are to take place between smart process objects.Some of these inputs and outputs may be defined as being connected tothe smart process objects connected at the predefined connection pointsfor the smart process object as discussed above. These inputs 54 andoutputs 56 may also be determined or defined by a set of rules withinthe rule database 50 and the connection matrix 52 defining theconnections between different devices or entities within the plant 10.The inputs 54 and the outputs 56, which include data stores or buffersassociated therewith will, generally speaking, be used to providecommunications of data from other smart process objects to the smartprocess object 42 e or to provide communications of data stored withinor generated by the smart process object 42 e to other smart processobjects. These inputs and outputs may also be used to providecommunications between the smart process object 42 e and other objectswithin the process control system, such as control modules within thecontrollers 12, field devices 14, 16, etc.

As illustrated in FIG. 2, the smart process object 42 e also includes amethod storage 58 that is used to store zero, one or more methods 60(illustrated as methods 60 a, 60 b, and 60 c in FIG. 2) to beimplemented by the smart process object 42 e during execution of aprocess flow module by the execution engine 48. Generally, the methods60 stored in the method storage 58 will use the data stored within thedata storage portions 53 a and 53 b and data obtained from other smartprocess objects or even data from other sources, such as theconfiguration database or historian 28, via the inputs 54 and theoutputs 56 to determine information about the process plant 10 or anentity within the plant 10. For example, the methods 60 may determinepoor or bad operating conditions associated with the entity defined bythe smart process object 42 e, errors associated with that or otherentities within the process plant 10, etc. The methods 60 may bepreconfigured or provided based on the type or class of smart processobject and will generally be executed each time the smart process object42 e is executed within the execution engine 48 during runtime. Someexample methods 60 that may be provided within a smart process object,such as the smart process object 42 e, include detecting leaks, deadhand, dead time, movement, variability, condition monitoring, or otherconditions associated with the entity. The methods 60 may also beprovided to help calculate mass balances, flows and other system-levelconditions associated with the plant 10. Of course, these are but a fewof the methods that can be stored in and run by a smart process object,and there are many other methods that may be used, with such methodsgenerally being determined by the type of entity being represented, themanner in which that entity is connected in and used in a process plantas well as other factors. While the smart process object 42 e may storeand execute methods that detect system-level conditions, errors, etc.,these methods may also be used to determine other information aboutdevices, logical elements, such as process control modules and loops,and other non-system-level entities. If desired, the methods 60 may beprogrammed or provided in any desired programming language, such as C,C++, C#, etc. or may be references to or may define applicable ruleswithin the rule database 50 that should be run for the smart processobject 42 e during execution.

During execution of the smart process object by the execution engine 48,the engine 48 implements the communications defined by the inputs 54 andoutputs 56 to each of the smart process objects in a process flow module44 and may implement the methods 60 for each of those objects to performthe functionality provided by the methods 60. As noted above, thefunctionality of the methods 60 may be located in programming within thesmart process object or defined by a set of rules within the ruledatabase 50 that the engine 48 executes, based on the type, class,identification, tag name, etc. of a smart process object, to implementthe functionality defined by those rules.

It will be noted that the smart process object 42 e has a tag or uniquename associated therewith that may be used to provide communications toand from the smart process object 42 e and to be referenced by theexecution engine 48 during runtime. Still further, the parameters of thesmart process object 42 e can be simple parameters, such as simplevalues, or smart parameters that know the expected units associatedtherewith. Smart parameters can be interpreted and used by the processrules engine or execution engine 48 to assure all signals are being sentin the same units or are converted properly. Smart rules can also beused to turn on and turn off groups of alarms for the smart processobjects (or process flow modules) to create a smart alarm strategyand/or interface for the operator. Still further, smart process objectclasses can be associated with equipment and module classes within theprocess control strategy of the plant 10 to provide a known linkagebetween a smart process object and the process variables it will need tointerpret or access.

Smart process objects may also include mode, status, and alarm behaviorso that these smart objects may be put in different modes duringruntime, such as manual, cascade or automatic modes, may provide astatus associated with the object based on its current operating state,and may provide alarms based on detected conditions, such as a parameterout of range, limited, high variability, etc. Smart process objects mayalso have a class/subclass hierarchy which enables them to becategorized in class libraries, to be collected together in a compositestructure, etc. Still further, smart process objects may be acquired andreleased by other elements, such as control modules and other objects toenable the smart process object to recognize when its associated entityis busy or, for example, acquired by a batch control process within theplant 10.

Smart process objects may be associated with any desired process entity,such as physical devices like pumps, tanks, valves, etc., or logicalentities such as process areas, process loops, process control elementslike process control modules, etc. In some cases, smart process objectsmay be associated with connectors, such a piping, conduit, wiring,conveyors belts, or any other device or entity that moves material,electricity, gas, etc. from one point to another point within theprocess. Smart process objects that are associated with connectors,referred to herein as smart links, are also tagged (even though thedevice or connector itself may not be tagged or able to communicatewithin the process plant 10), are generally used to represent processflow between smart process objects.

Smart links will typically include properties or parameters that definehow different materials or phenomena (such as electricity) flow throughthe connection (e.g. steam, electricity, water, sewage, etc.) Theseparameters may indicate the type and nature of flow (such as the generalspeed, friction coefficients, type of flow like turbulent ornon-turbulent, electromagnetic, etc.) through the connector and thepossible direction or directions of flow through the connector. Smartlinks may include programming or methods that ensure that the units ofthe source and destination object to which the smart link connects,match and, if not, may perform a conversion. The methods of the smartlink may also model the flow through the connector using a model or analgorithm to estimate the speed or nature of the flow through the actualconnectors. The stored parameters for the smart process object (such asfriction parameters) may be used in these methods. Thus, in essence, thesmart links enable smart process objects to be aware of the otherobjects upstream and downstream of them. Of course, smart links may, forexample, define the connections between other objects, the type offluid, such as liquid, gas, electricity, etc. within the system, theupstream and downstream side of the entities, which other entities areupstream and downstream of the entity for this smart process object, thedirection of material, fluid, electric flow, etc. in any desired orconvenient manner. In one embodiment, the matrix 52 may be created priorto execution of process flow modules and may define for the smart linksthe interconnections between the different devices within the plantarid, therefore, the interconnections between the different smartprocess objects. In fact, the execution engine 48 may use the matrix 52to ascertain the upstream and downstream entities and thereby define thecommunications between the smart process objects and the methodsassociated with the smart process objects. Still further, one or moresets of rules may be provided to be used by the smart process objects tointeract with each other and to obtain data from each other as neededfor the methods within the smart process objects.

If desired, the smart process object 42 e may provide hot links, such asURLs, to key documentation which may be applicable to the type ofobject, or which may be specific to the instance (depending on thecriticality) of the device to which the smart process object 42 epertains. The documentation may be vendor supplied as well asuser-specific. Some examples of documentation include configuration,operational and maintenance documentation. If desired, an operator mayclick on the object as displayed in an operator display to bring up theinstance specific (if any) and generic documentation for the object orassociated device. Also, the operator may be able to add/delete/changedocumentation independently of the system software. Furthermore, thesehot links may be user configurable or changeable to provide the abilityto add knowledge links to objects in the operator interface, to providefor quick navigation to appropriate information associated with theobject and to provide the ability to add work instructions specific tothe customer, or specific to the object type or even specific to theinstance of the object.

Generally speaking, an operator may run or execute the configurationapplication 38 to create one or more process flow modules 44 forimplementation during operation of the process 10. In one embodiment,the configuration application 38 presents a configuration display, suchas that illustrated in FIG. 3, to the operator. As seen in FIG. 3, aconfiguration display 64 includes a library or template section 65 and aconfiguration section 66. The template section 65 includes a depictionof sets of template smart process objects 67 (which may include thesmart process objects 42 of FIG. 2) and non-smart elements 68.Essentially, the templates 67 and 68 are generic objects that may bedragged and dropped onto the configuration section 66 to create aninstance of a smart process object within a process flow module. Apartially completed process flow module 44 c is illustrated as includinga valve, two tanks, two pumps, a flow transmitter and two sensorsinterconnected by flow path connectors, which may be smart links. Itwill be noted that the process flow module 44 c may be made up of bothsmart process objects and non-smart elements.

When creating a process flow module, such as the process flow module 44c, the operator may select and drag the smart process objects 67 and theelements 68 illustrated in the template section 65 onto theconfiguration section 66 and drop them there in any desired location.Generally, the operator will select and drag one or more smart deviceprocess objects 67 a or non-smart elements 68 depicting devices onto theconfiguration section 66. The operator will then interconnect the smartdevice process objects and non-smart device elements depicted within theconfiguration section 66 with smart connector process objects 67 b ornon-small elements 68 depicting connectors. The operator may change theproperties of each of the smart process objects and non-smart elementsduring this process using pop-up properties menus, etc. and, inparticular, may change the methods, parameters, tags, names, hot links,modes, classes, inputs and outputs, etc. associated with these smartprocess objects. When the operator has created a process flow modulewith each of the desired elements, typically representing a processconfiguration, area, etc., the operator may define rules or otherfunctionality associated with the module. Such rules may be executionrules such as those associated with the performance of system-levelmethods, like mass balance and flow calculations which are to beperformed during operation of the module 44 c. After creating the module44 c, the operator may save that module in the module memory 46 of FIG.2 and may, at that time, or later, instantiate and download that processflow module to the execution engine 48 in a manner that the executionengine 48 may operate the process flow module 44 c.

If desired, the smart process objects within a process flow module maybe provided a specific tag or may be provided with a tag including analias that can be filled in or selected at runtime by, for example, theexecution engine 48 based on other factors, such as a piece of equipmentor a route selected within the process control system. The use of aliasnames and indirect referencing in process control systems is discussedin detail in U.S. Pat. No. 6,385,496, which is assigned to the assigneeof the present invention and which is hereby expressly incorporated byreference herein. Any of these techniques may be used to provide andresolve aliases in tags for the smart process objects described herein.With the use of aliases and the like, the same process flow module mayinclude or be used to support different views for sets of equipment,etc.

The display 64 of FIG. 3 illustrates tabs (View 1, View 2 and View 3)for different views of the process flow module 44 c. These tabs may usedto access and create different views associated with the process flowmodule 44 c using some of the same smart process objects therein. Theuse of alias names in one or more of these views enables, for example, arouting executive or view which defines a route for process flow withinthe process plant during runtime to use the module 44 c of View 1 eventhough different actual devices used within the route are specifiedafter creation of the process flow module 44 c. In effect, the smartprocess objects may be connected to and become associated with differentprocess entities at different times during runtime. Thus, with the useof alias names, the process flow modules are not limited to staticbinding between the graphic user display and the process flow database.As an example, a view (such as View 2 of FIG. 3) may be associated withrouting routine which may be used by an operator to select a routethrough different ones of the process entities. Upon selection of theroute, thereby specifying specific process entities, the tag names oralias names in the other views may be filled in, thereby changing orspecifying the behavior for these views.

Generally speaking, when the operator creates a process flow module, theconfiguration application 38 automatically stores the smart processobjects, along with the connections therebetween, in a process flowdatabase. This process flow database can then be used to create otherprocess flow modules which may, for example, provide a different viewusing one or more of the same smart process objects. As such, whencreating the second view, the operator can simply reference the smartprocess object, as already created and stored within the process flowdatabase, and any methods, etc. stored therewith to place that smartprocess object in the second view. In this manner, the process flowdatabase can be populated as the process control modules are created andthe process flow database can be used at any time to create and executeother views, modules, and graphic displays using smart process objectswhich already exist within the process flow database. Using such aprocess flow database, each smart process object within the process flowdatabase may support or be used in different process flow modules and indifferent views or displays for those process flow modules. As will alsobe understood, the process flow modules are constructed or built bybuilding displays for these modules and then specifying flow algorithmsto be used in or associated with these process flow modules. Of course,individual process flow modules may be spread across and executed bydifferent computers and process flow modules may be communicativelyconnected to one other to operate in conjunction with each other, eitheron the same or on different computers.

As noted above, the operator may, as part of the process flow modulecreation or configuration process, attach or provide process flowalgorithms to the process flow module. These process flow algorithms maybe preconfigured to calculate or determine certain process orsystem-level properties, such as mass balance calculations, flowcalculations, efficiency calculations, economic calculations, etc. withrespect to the process depicted or modeled by the process flow module.As a result, the process flow modules themselves may have mode, status,and alarm behavior, can be assigned to workstations, and may bedownloaded as part of the display downloads. if desired, the flowalgorithms may be executed by a separate or different execution engineor by the execution engine 48 to perform mass or heat balancing, flowrouting, flow efficiency, flow optimization, economic calculationsrelated to flow or other desired flow related calculations using thedata provided in the smart process objects of the process flow module.Still further, these flow algorithms may access parameters from thecontrol strategy, i.e., the control modules associated with anddownloaded to the controllers, field devices, etc. and may, conversely,provide data or information to these control modules.

The execution of these flow algorithms may be enabled and disabled bythe operator on a module by module basis at any given time. Likewise,the operation of these flow algorithms may be verified and debugged inany desired manner prior to the process flow module being downloaded tothe execution engine 48. Similar to the smart process objects, theprocess flow modules or the flow algorithms associated therewith may beacquired and released by other entities within the process controlsystem or plant 10. In order to take on this intelligent behavior,displays for the process flow modules may be built from display classeswhich can optionally have one or more of the process flow algorithmsassociated therewith. To engage a process flow algorithm the user mayselect the display and enable the special behavior (e.g. mass balance,flow calculation, etc.) which will take effect over the span of thesmart process objects defined on the display. To perform thisfunctionality, the process flow algorithms should be associated with aparticular workstation which can be defined as a property of the displayor display class.

It will be understood that the execution engine 48 is needed to enablethe process flow algorithms to execute across an amalgamation of allprocess objects and links configured on all displays. Thus, the processflow algorithms will generally execute regardless of whether any displayis loaded, i.e., called up and displaying information to a user. Ofcourse, the process flow algorithms may be cross-checked across theentire process 10 or across defined subsets of the process 10. It willalso be understood that, during execution of any particular process flowmodule, the execution engine 48 may provide a display to an operator onan operator interface depicting the interconnected objects or entitieswithin the process flow module based on the graphical representations ofthe smart process objects and the non-smart elements within that processflow module. The parameters, graphics, etc. of the display will bedetermined by the configuration and interconnection of the smart andnon-smart elements within the process flow module. Furthermore, alarmsand other information to be provided on this or other displays will bedefined and generated by the methods within the smart process objectsand the flow algorithms associated with a particular process flowmodule. If desired, the execution engine 48 may provide a display for aprocess flow module to more than one operator interface or may beconfigured or set to provide no display, even though the executionengine 48 continues to execute the process flow module and therebyperform the methods, alarm behavior, flow algorithms, etc. associatedtherewith.

FIG. 4 illustrates an example screen display 70 that may be generated bythe operator interface application 40 on the display 37 of theworkstation 20 of FIG. 1. The screen display 70 includes a depiction ofnumerous process plant entities as set up and configured within, forexample, the plant 10 of FIG. 1. In particular, fluid flow from a tankfarm is provided to a pump 72 which pumps liquid through a flowtransmitter 74 to a tank 76 having a measurement device, such as a levelsensor/transmitter 78, attached hereto. A pump 80 pumps liquid from thetank 76 through a valve 82, a flow transmitter 84 and a heat exchanger86 to a second tank 88 having a sensor/transmitter device 89 attachedthereto. The tank 88 provides a first output through a flow transmitter90 and a heat exchanger 92 to a third tank 94 having a measurement orsensor device 95 thereon. The tank 94 provides an output through a heatexchanger 96 and a flow transmitter 98 to a distillation column. Thetank 94 also provides an output via a pump 100, a flow transmitter 101and a valve 102 back to the input of the heat exchanger 86. Similarly, asecond output of the tank 88 is pumped by a pump 104 through a valve 106and a flow transmitter 108 to a stepper column. While the entitiesdepicted in the screen display 70 include tanks, pumps, flowtransmitters, valves, lines, etc., connected in a particularconfiguration, any other process entities, including hardware devicesand software or logical elements such as control loops, control modules,function blocks, etc. may be depicted within the screen display 70 inany desired configuration. Still further any of the devices, such as thetanks, transmitters, valves, etc. as well as the connectors therebetweendepicted on the screen 70 may be generated by or associated with smartprocess objects within a process flow module used to create the display70 during runtime of that module.

As will be understood, at least some of the interconnected entitieswithin the screen display 70 are configured using the configurationapplication 38 and may be displayed on the display screen 70 by theexecution engine 48 during runtime of a process flow module based on thesmart process objects and other elements within the process flow modulebeing executed. For example, the tanks 76, 88 and 94, the flowtransmitters 74, 84, 90, 98, 101 and 108 and the sensor/transmitterdevices 78, 89 and 95 as well as one or more of the connectorsconnecting these elements may be generated on the display screen 70 bysmart process objects associated therewith. Of course, only some ofthese entities need to have smart process objects associated therewith.

During operation of the execution engine 48, the smart process objectsassociated with the entities of module depicted in FIG. 4 obtain datafrom the actual hardware (or software) entities associated therewith andmay, in some cases, display this data to the operator on the screen 70as part of or as associated with graphical element of the smart processobject. Example data displays are illustrated for the flow transmitters74, 84, 90 and 98 as well as for the level sensors 78 and 89. Of course,certain ones of the smart process objects may be communicatively coupledtogether to send data to and obtain data from one another to be able toperform methods associated therewith. For example, the smart links mayobtain data regarding flow, etc. from other ones of the smart processobjects within the process flow module depicted in FIG. 4. As indicatedabove, the methods for the smart process objects may perform any desiredfunctions on the data obtained by and sent to the smart process objectsto detect operating or other conditions within the plant 10, includingerrors or other adverse (or potentially good) conditions associated withthe process plant 10 or devices thereof.

In one example the tank 88, the sensor transmitter 89, which may be alevel sensor, and the flow transmitters 84, 90, 101 and 108 (which areflow sensor devices) may each be associated with a different smartprocess object and be generated on the screen 70 using a smart processobject. These smart process objects are communicatively tied to, andobtain data from the different devices with which they are associated.Thus, the smart process objects for the flow transmitters 84, 90, 101and 108 obtain the readings of the flow through those actual devices asmeasured by those devices in the plant 10. Likewise, the smart processobject for the sensor transmitter 89 is tied to and obtains themeasurements made by the actual sensor pertaining to the level of thetank 88. Likewise, a smart process object for the tank 88 may becommunicatively tied to each of the smart process objects for the flowtransmitters 84, 90, 101 and 108 and the smart process object for thelevel sensor 89. The smart links connected to the tank 88 may specifythe flow direction and upstream and downstream points associated withthe flow transmitters 84, 90, 101 and 108. A method stored in orassociated with the smart process object for the tank 88 may use thedata from the smart process objects for the transmitters 84, 90, 101,108 and 89 and the heat exchangers 86 and 92, to determine if the tank88 is leaking or losing BTUs (heat balance calculations). This methodmay operate by first determining the (instantaneous, average, integral,etc.) flow into the tank 88 as the sum of the flows measured by the flowtransmitters 84 and 101 and then determining the outflow from the tankas the Sum of the flows measured by the flow transmitters 90 and 108.The method may then determine the difference between these flows, asintegrated over time, as the amount of fluid being added to (orsubtracted from) the tank 88. The method may next ascertain if thischange in the amount of fluid within the tank 88 over a particularamount of time is reflected by the difference in the level of the tank88 as measured by the level sensor 89. If the level over the particularperiod of time, for example, increases less than expected, then themethod associated with the tank 88 may detect and indicate to theoperator that the tank 88 may be leaking fluid. Similarly, an increasein the level over the amount expected based on the obtained measurementsmay be used to detect or determine a faulty sensor or measurement devicewithin this part of the plant 10. This technique can also be used toprovide redundancy in measurements to, for example, cross checkmeasurements or data with other related measurements thereby, inessence, making more measurements than absolutely required. Of course,any difference in the expected level and the measured level may beindicated to the operator as an error or an alarm, such as an advisoryalarm.

In another example, a smart process object may be created andimplemented for the pump 72 and the flow transmitter 74. The smartprocess object for the pump 72 may be aware that it is connected toequipment within the tank farm and to the flow transmitter 74 and mayreceive data from the smart process objects for these entities. A methodassociated with the smart process object for the pump 72 may receive thedata from the smart process object for the flow transmitter 74 anddetermine the variability of the flow as measured by the flowtransmitter 74. (If desired, a method associated with the smart processobject for the flow transmitter 74 may determine the variability of thattransmitter, or an application within the transmitter 74 itself maydetermine the transmitter variability and provide this determination asdata to the smart process object for the transmitter 74.) In any event,if the variability for the transmitter 74 exceeds a certain limit, themethod for the pump smart process object may notify the operator of thehigh variability using an alarm, such as an advisory alarm. Of course,these are only a couple of methods that may be implemented to performfunctionality at the operator interface level to detect conditions, suchas problems, errors, alarms, etc. within the plant 10 and other methodsmay be provided and used as well.

Still further, the execution engine 48 (which may have a separateexecution engines for implementing displays and methods associated withsmart process objects and for implementing flow algorithms associatedwith process flow modules) may implement flow algorithms associated withone or more process flow modules to calculate mass balances, flows, etc.for the portion of the plant depicted by those modules. The executionengine 48 may, as part of this process, provide information or data tothe other elements within the process plant 10, such as to processcontrol modules running in the controllers 12 of the plant 10.

It will be understood that the functionality of the smart processobjects and process flow modules operates in the operator workstation 20and does not need to be downloaded to and configured within thecontrollers, field devices, etc. within the plant 10, which makes thisfunctionality easier to implement, view, change, etc. Further, thisfunctionality enables system level determinations to be made more easilythan down within the process devices, controllers, etc. because theinformation pertaining to the devices on a system level is all typicallyavailable to the operator workstation 20 in general and to the executionengine 48 in particular whereas all of this information is not typicallymade available to each controller and field device within the processplant 10. However, when it is advantageous to do so, some of the logicassociated with the process flow modules, such as primitives, may beembedded in the devices, equipment and controllers down within theprocess plant. The use of smart process objects enables the executionengine 48 to, for example, automatically detect leaks and produce alarmswith no or only minimal amounts of user configuration activities, tocalculate and track flow and mass balances within the plant 10, to tracklosses within the plant 10 and to provide higher level diagnostics forthe plant 10.

If desired, methods or rules may be established generically and appliedto the different smart process objects and process flow modulesgenerally or on a system-wide basis to detect and track loses, flows,variability, etc. within the plant 10 as well as to provide alarming andother condition detection within the plant 10 based on the configurationof the plant 10 as reflected in the smart process objects and processflow modules. These rules may be applied based on the type and nature ofthe smart process objects, what material is supported, such as liquid,gas, electricity, etc. and the connections between the objects asdefined by the connection matrix 52 described above or any otherinformation defining the interconnections between the devices within theplant 10 and, therefore, the interconnections between the smart processobjects.

FIG. 5 depicts one possible manner of integrating the execution engine48 and process flow modules used thereby within a process plant have adistributed control strategy associated therewith. As illustrated inFIG. 5, the display class definitions 120 as created by the process flowmodules for providing displays to an operator during execution by theexecution engine 48 are provided to the control configuration databaseand engineering tools 122 which may use and organize these display classdefinitions in any desired manner within the control strategydocumentation. Process flow algorithms 124 may be connected to thesedisplay class definitions prior to runtime and then the display classdefinitions and flow algorithms bound thereto are instantiated andprovided to the process flow module runtime environment 126 (which maybe implemented in the form of one or more execution engines 48 indifferent operator workstations). The process flow module runtimeenvironment 126 uses a download script parser 128 to parse the codeduring execution (i.e., to perform just in time object code conversion)and uses a ruled-based execution engine 130 to execute flow algorithmsor other rule based procedures provided for or bound to the displayclasses. During this process, the process flow module runtimeenvironment 126 may communicate with the control module runtimeenvironment 132, which may be executed in controllers and field devicesassociated with the process, to provide data or information to thecontrol module runtime environment 132 or to access data or otherinformation from the control module runtime environment 132. Of course,the process flow module runtime environment 126 may communicate with thecontrol module runtime environment 132 using any desired orpreconfigured communication networks, such as the Ethernet bus 24 ofFIG. 1. Of course, other methods of integrating the process flow modulesand smart process objects described herein into a standard processcontrol system or process plant may be used as well.

When implemented, any of the software described herein may be stored inany computer readable memory such as on a magnetic disk, a laser disk,or other storage medium, in a RAM or ROM of a computer or processor,etc. Likewise, this software may be delivered to a user, a process plantor an operator workstation using any known or desired delivery methodincluding, for example, on a computer readable disk or othertransportable computer storage mechanism or over a communication channelsuch as a telephone line, the Internet, the World Wide Web, any otherlocal area network or wide area network, etc. (which delivery is viewedas being the same as or interchangeable with providing such software viaa transportable storage medium). Furthermore, this software may beprovided directly without modulation or encryption or may be modulatedand/or encrypted using any suitable modulation carrier wave and/orencryption technique before being transmitted over a communicationchannel.

While the present invention has been described with reference tospecific examples, which are intended to be illustrative only and not tobe limiting of the invention, it will be apparent to those of ordinaryskill in the art that changes, additions or deletions may be made to thedisclosed embodiments without departing from the spirit and scope of theinvention.

What is claimed is:
 1. An object entity within an object orientedprogramming environment for use in viewing and providing functionalityin a process plant, the object entity comprising: a computer readablememory; an object stored on the computer readable memory and executableon a processor, the object representing a process entity within theprocess plant and including: a data storage which stores (i) parameterdata for the process entity corresponding to the object and (ii) one ormore data inputs or outputs which communicate with other objectsrepresenting other process plant entities within the process plant; agraphic representation of a process entity corresponding to the object;and a method memory storage that stores one or more methods, which whenexecuted on the processor, perform functions related to the processentity using at least one of the parameter data and the one or more datainputs or outputs for the process entity corresponding to the object.